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Abstract 


New fields are occasionally added to civic addresses. A backward- 
compatible mechanism for adding civic address elements to the Geopriv 
civic address format is described. A formal mechanism for handling 
unsupported extensions when translating between XML and DHCP civic 
address forms is defined for entities that need to perform this 
translation. Initial extensions for some new elements are also 
defined. The Location-to-Service Translation (LOST) protocol 
mechanism (defined in RFC 5222) that returns civic address element 
names used for validation of location information is clarified and is 
normatively updated to require a qualifying namespace identifier on 
each civic address element returned as part of the validation 
process. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6848. 
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Les 


Introduction 


The Geopriv civic location specifications ([RFC4776], [RFC5139]) 
define an XML and binary representations for civic addresses that 
allow for the expression of civic addresses. Guidance for the use of 
these formats for the civic addresses in different countries is 
included in [RFC5774]. 


Subsequent to these specifications being produced, use cases for 
extending the civic address format with new elements have emerged. 
[RFC5774] describes a mechanism for mapping long-standing address 
formats into the civic address elements defined in [RFC4776] and 


[RFC5139]. However, some of these existing address elements do not 
readily fit into the civic address elements defined in [RFC4776] and 
[RFC5139]. In these cases, creating new civic address elements 


provides a better solution than overloading existing civic address 
fields, which may cause confusion. 


The XML format for civic addresses [RFC5139] provides a mechanism 
that allows for the addition of standardized or privately understood 
elements. A similar facility for private extension is not provided 
for the DHCP format [RFC4776], though new specifications are able to 
define new CAtypes (civic address types). 


A recipient of a civic address in either format currently has no 
option other than to ignore elements that it does not understand. 
This results in any elements that are unknown to that recipient being 
discarded if a recipient performs a translation between the two 
formats. In order for a new extension to be preserved through 
translation by any recipient, the recipient has to understand the 
extension and know how to correlate an XML element with a CAtype. 


This document describes how new civic address elements are added. 
Extensions always start with the definition of XML elements. A 
mechanism for carrying the extension in the DHCP format is described. 
A new XML namespace containing a small number of additional civic 
elements is also defined and can be used as a template to illustrate 
how other extensions can be defined as required. 


These mechanisms ensure that any translation between formats can be 
performed consistently and without loss of information. Translation 
between formats can occur without knowledge of every extension that 
is present. 


The registry of numeric CAtypes is modified so that the creators of 
extensions can advertise new namespaces and civic elements to 
encourage maximum reuse. 


Winterbottom, et al. Standards Track [Page 3] 


RFC 6848 Civic Extensions January 2013 


The additions described in this document are backwardly compatible. 
Existing implementations may cause extension information to be lost, 
but the presence of extensions does not affect an implementation that 
conforms to either [RFC4776] or [RFC5139]. 


This document also normatively updates [RFC5222] to clarify that the 
namespace must be included with the element name in the lists of 
valid, invalid, and not checked elements in the <locationValidation> 
part of a Location-to-Service Translation (LOST) response. While the 
LoST schema does not need to be changed, the example in the document 
is updated to show the namespaces in the lists. 


1.1. Motivating Example 


One instance where translation might be necessary is where a device 
receives location configuration using DHCP [RFC4776]. Conversion of 
DHCP information to an XML form is necessary if the device wishes to 
use the DHCP-provided information in a range of applications, 
including location-based presence services [RFC4079] and emergency 
calling [RFC5012]. 


| DHCP | DHCP | Device | XML | Recipient | e.g., Presence 
| Server |--------- >| |-------- >| | Agent 


Figure 1: Conversion Scenario 


The device that performs the translation between the DHCP and XML 
formats might not be aware of some of the extensions that are in use. 
Without knowledge of these extensions and how they are represented in 
XML, the device is forced to discard them. 


These extensions could be useful, or may be critical, to the ultimate 
consumers of this information. For instance, an extension element 
might provide a presence watcher with important information in 
locating the device, or an extension might be significant in choosing 
a particular call route. 


1.2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2. Specifying Civic Address Extensions 


The civic schema in [RFC5139] defines an ordered structure of 
elements that can be combined to describe a civic address. The XML 
extension point at the end of this sequence is used to extend the 
address. 


New elements are defined in a new XML namespace [XMLNS]. This is 
true of address elements with significance within private or 
localized domains as well as those that are intended for global 
applicability. 


New elements SHOULD use the basic "caType" schema type defined in 
[RFC5139]. This type provides an optional "xml:lang" attribute. 


For example, suppose the (fictitious) Central Devon Canals Authority 
wishes to introduce a new civic element called "bridge". The 
authority defines an XML namespace that includes a "bridge" element. 
The namespace needs to be a unique URI, for example 
"http://devon.canals.example.com/civic". 


A civic address that includes the new "bridge" element is shown in 
Figure 2. 


<civicAddress xml:lang="en-GB" 

xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmlns:cdc="http://devon.canals.example.com/civic"> 

<country>UK</country> 

<A1>Devon</A1> 

<A3>Monkokehampton</A3> 

<RD>Deckport</RD> 

<STS>Cross</STS> 


<cdc:bridge>21451338</cdc:bridge> 


</civicAddress> 


Figure 2: Extended Civic Address Example 


An entity that receives this location information might not 
understand the extension address element. As long as the added 
element is able to be safely ignored, the remainder of the civic 
address can be used. The result is that the information is not as 
useful as it could be, but the added element does not prevent the use 
of the remainder of the address. 


The address can be passed to other applications, such as a LoST 
server [RFC5222], without modification. If the application 
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understands the added element(s), it is able to make use of that 
information. For example, if this civic address is acquired using 
HTTP-Enabled Location Delivery (HELD) [RFC5985], it can be included 
in a LoST request directly. 


3. Translating Unsupported Elements 


Unsupported civic address elements can be carried without consequence 
as long as the format of the address does not change. However, 
conversion between formats has been shown to be necessary. 


Format conversion requires knowledge of the format of the address 
elements. An entity performing a conversion between XML and DHCP 
address formats is forced to discard unrecognized elements. The 
entity performing the conversion has no way to know the correct 
element to use in the target format. 


This document defines a single extension element for the DHCP format 
that makes knowledge of extensions unnecessary during conversion. 
This extension element relies on the extension mechanisms defined for 
the XML format. New extensions to the civic address format MUST be 
defined only for the XML format; these extensions are then conveyed 
in DHCP using the extension element. 


Further extensions to the DHCP format are prohibited; these 
extensions cannot be safely conveyed in environments where conversion 
is possible. 


3.1. XML to DHCP Format Translation 


Extensions to the XML format [RFC5139] are defined in a new XML 
namespace [XMLNS]. The XML namespace received in DHCP is expressed 
as a URL, however, it should not be dereferenced or treated as a 
source location for the actual schema and doing so will serve no 
useful purpose. 


Extensions in the XML format can be added to a DHCP format civic 
address using an extension CAtype. 


3.2. Extension Civic Address Type (CAtype) 


The extension CAtype (CAtype code 40) includes three values that 
uniquely identify the XML extension and its value: a namespace URI, 
the local name of the XML element, and the text content of that 
element. These three values are all included in the value of the 
CAtype, each separated by a single whitespace character. 
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Oi D2. 35-4546 7 8D O 2°34 E 67 89 O12 3 4S 6 7 8 a O 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CAtype (40) | Length | Namespace URI z 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Namespace URI (continued) 


-+-+-+-+-+-+-+-+-+-+-+-+-+t tH 
Space (U+20) | XML element local name 
=-=- + 


+—+. 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Space (U+20) | Extension type value 


+— +. 


t-+—+-4+-+-4+-4+-4+-4t-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4+-4+-4-4-4 
Figure 3: XML Civic Address Extension CAtype 
CAtype (40) identifies the extension CAtype. 


Length is the number of octets used to represent the namespace URI, 
local name, and value. The length includes the space between the 
namespace URI and local name and the space between the local name and 
value fields. 


The content of a CAtype (after the CAtype code and length) is UTF-8 

encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. 
Octets consumed by the namespace URI and local name reduce the space 
available for values. 


This conversion only works for elements that have textual content and 
an optional "xml:lang" attribute. Elements with complex content or 
other attributes -- aside from namespace bindings -- MUST be ignored 
if they are not understood. 


3.3. DHCP to XML Format Translation 
The registration of a new CAtype following the process in [RFC4776] 


means that a recipient that does not know the equivalent XML is 
unable to produce a complete XML representation of the DHCP civic 


address. For this reason, this document ends the registration of new 
numeric CAtypes. No new registrations of numeric CAtypes can be 
made. 
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In lieu of making new numerical CAtype assignments, this document 
creates a new extensionCA type that is defined in a manner that lets 
new civic elements be described in DHCP form by carrying the 
namespace and type name of the extension in parameters of the 
extensionCA type. 


When converting to XML, the namespace prefix used for the extension 
element is selected by the entity that performs the conversion. 


3.4. Conversion Example 
The following example civic address contains two extensions: 


<civicAddress xml:lang="en-US" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmlns:post="http://postsoftheworld.example.com/ns" 
xmlns:ap="http://example.com/airport/5.0"> 
<country>US</country> 
<A1>CA</A1> 


<post:lamp>2471</post:lamp> 
<post :pylon>AQ-374-4 (c) </post:pylon> 


<ap:airport>LAX</ap:airport> 
<ap:terminal>Tom Bradley</ap:terminal> 
<ap:concourse>G</ap: concourse> 
<ap:gate>36B</ap:gate> 

</civicAddress> 


Figure 4: XML Example with Multiple Extensions 


This is converted to a DHCP form as follows: 


country = US 

CAtype [0] = en-US 

CAtype[1] = CA 

CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471 
CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4 (c) 
CAtype[40] = http://example.com/airport/5.0 airport LAX 

CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley 
CAtype[40] = http://example.com/airport/5.0 concourse G 

CAtype[40] = http://example.com/airport/5.0 gate 36B 


Figure 5: Converted DHCP Example with Multiple Extensions 
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4. CAtypes Registry 


[RFC4776] created the CAtype registry. Among other things, this 
registry advertised available civic elements. While it has always 
been possible to use an extension namespace to define civic elements 
that are not in the CAtype registry, and this document does not 
change that, the registry is valuable to alert implementors of 
commonly used civic elements and provides guidance to clients of what 
elements they should support. 


This document alters the CAtype registry in several ways. It closes 
the registry to new numeric CAtypes. It deletes the "NENA" column, 
which is not needed. It adds columns for a namespace and contact, 
and changes the name of the column currently called "PIDF" to "Local 
Name". It also adds a column to the registry called "Type". "Type" 
can have one of two values "A" and "B". Type A elements are intended 
for wide use with many applications and SHOULD be implemented by all 
clients unless the client is certain the element will not be 
encountered. Type B civic elements MAY be implemented by any client. 


Type A civic elements require IETF review, while Type B elements only 
require an expert review. 


5. Civic Extensions 


We use this new extension method to define some additional civic 
address elements that are needed to correctly encode civic locations 
in several countries. The definition of these new civic address 
elements also serves as an example of how to define additional 
elements using the mechanisms described in this document. 


5.1. Pole Number 


In some areas, utility and lamp posts carry a unique identifier, 
which we call a pole number in this document. In some countries, the 
label on the lamp post also carries the local emergency service 
number, such as "110", encouraging callers to use the pole number to 
identify their location. 
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Figure 6: Lamp Post with Emergency Number 
-2. Milepost 


On some roads, trails, railroad rights of way, and other linear 
features, a post with a mile or kilometer distance from one end of 
the feature may be found (a "milepost"). There are other cases of 
poles or markers with numeric indications that are not the same as a 
"house number" or street address number. 


-3. Street Type Prefix 


The civic schema defined in [RFC5139] allows the definition of 
address "123 Colorado Boulevard", but it does not allow for the easy 
expression of "123 Boulevard Colorado". Adding a street type prefix, 
allows a street named in this manner to be more easily represented. 


-4. House Number Prefix 


The civic schema defined in [RFC5139] provides a house number suffix 
element, allowing one to express an address like "123A Main Street", 
but it does not contain a corresponding house number prefix. The 
house number prefix element allows the expression of address such as 
"Z123 Main Street". 
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5.5. XML Extension Schema 


<?xml version="1.0"?> 

<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext" 
xmilns:ca="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:cae="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext" 
xmlns:xml="http://www.w3.org/XML/1998/namespace" 
elementFormDefault="qualified" attributeFormDefault="unqualified"> 


<xs:import namespace="urn:ietf:params:xml:pidf:geopriv1l0:civicAddr"/> 


<!-—- Post Number --> 
<xs:element name="PN" type="ca:caType"/> 


<!-- Milepost --> 
<xs:element name="MP" type="ca:caType"/> 


<!-- Street Type Prefix --> 
<xs:element name="STP" type="ca:caType"/> 


<!-- House Number Prefix --> 
<xs:element name="HNP" type="ca:caType"/> 


</xs:schema> 


5.6. Extension Examples 


<civicAddress xml:lang="en-US" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmlns:cae="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext"> 
<country>US</country> 
<A1>CA</A1> 
<A2>Sacramento</A2> 
<RD>1I5</RD> 
<cae:MP>248</cae:MP> 
<cae:PN>22-109-689</cae:PN> 
</civicAddress> 


Figure 7: XML Example with Post Number and Milepost 
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<civicAddress xml:lang="en-US" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmilns:cae="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext"> 
<country>US</country> 
<A1>CA</A1> 
<A2>Sacramento</A2> 
<RD>Colorado</RD> 
<HNO>223</HNO> 
<cae:STP>Boulevard</cae:STP> 
<cae:HNP>A</cae:HNP> 
</civicAddress> 


Figure 8: XML Example with Street Type Prefix and House Number Prefix 
6. Using Local Civic Extension with the LoST Protocol 


One critical use of civic location information is in next generation 
emergency services applications, in particular, call routing 
applications. In such cases, location information is provided to a 
location-based routing service using the LoST protocol [RFC5222]. 
LoST is used to provide call routing information, but it is also used 
to validate location information to ensure that it can route to an 
emergency center when required. 


LoST is an XML-based protocol, and so the namespace extension 
mechanisms described in this document do not impact LoST. When LoST 
is used for validation, a <locationValidation> element is returned 
containing a list of valid, a list of invalid, anda list of 
unchecked civic elements. Figure 9 is an extract of the validation 
response in Figure 6 from [RFC5222]. 


<locationValidation> 
<valid>country Al A3 A6</valid> 
<invalid>PC</invalid> 
<unchecked>HNO</unchecked> 
</locationValidation> 


Figure 9: Location Validation Example from LoST (RFC5222) 


The RelaxNG schema in [RFC5222] requires the elements in each of 
these lists to be namespace qualified, which makes the example in 
Figure 6 of [RFC5222] erroneous. This issue is especially 
significant when local-civic extensions are used as the domain to 
which the extensions are attributed may impact their interpretation 
by the server or client. To ensure that local-civic extensions do 
not cause issues with the LoST server and client implementations, all 
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elements listed in a <valid>, <invalid>, or <unchecked> element MUST 
be qualified with a namespace. To illustrate this, the extract above 
from Figure 6 in [RFC5222] becomes Figure 10. 


<locationValidation 
xmilns:ca="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr"> 
<valid>ca:country ca:Al ca:A3 ca:A6</valid> 
<invalid>ca:PC</invalid> 
<unchecked>ca:HNO</unchecked> 
</locationValidation> 


Figure 10: Corrected Location Validation Example 


If a validation request has also included the extensions defined in 
Section 5, then the validation response would look like Figure 11. 


<locationValidation 
xmilns:ca="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmilns:cae="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext"> 
<valid>ca:country ca:Al ca:A3 ca:A6 cae:PN cae:STP</valid> 
<invalid>ca:PC</invalid> 
<unchecked>ca:HNO cae:MP cae:HNP</unchecked> 
</locationValidation> 


Figure 11: Corrected Location Validation Example 
7. Security Considerations 


This document defines a formal way to extend the existing Geopriv 
civic address schema. While no security threats are directly 
introduced by this document, creators of new civic address extensions 
should refer to Sections 4.3.1 and 5.1 of [RFC3694] to understand the 
environments in which these new elements will be used. New elements 
should only be registered if the person or organization performing 
the registration understands any associated risks. 


Security threats applicable to the civic address formats are 
described in [RFC4776] DHCP and [RFC5139] XML. 


8. IANA Considerations 


This document alters the "CAtypes" registry in the Civic Address 
Types Registry established by [RFC4776]. 


8.1. CAtype Registration for Extensions 


IANA has allocated a CAtype code of 40 for the extension CAtype. 
Registrations using this code will be made below, in Section 8.4. 


Winterbottom, et al. Standards Track [Page 13] 


RFC 6848 Civic Extensions January 2013 


82°, 


Changes to the CAtype Registry 


TANA has made the following changes to the CAtype registry: 


(0) 


No registrations of new CAtype numbers in the Civic Address Types 
Registry are permitted, except by IESG Approval [RFC5226] under 
unusual circumstances. 


The following note has been placed in the header of the CAtypes 
registry, above the table: 


Note: As specified in RFC 6848, new registrations are only 
accepted for CAtype 40, using the template specified in 


Section 8.3. 


The registration procedures are changed: IETF Review (if Type=A), 
Expert Review (if Type=B). The designated expert is unchanged. 


The reference for the table is changed: [RFC4776], RFC 6848 

The column called "NENA" is removed. 

The column called "PIDF" is renamed to "Local Name". 

New columns are added named "Namespace URI", "Contact", "Schema" 
and "Type". All existing entries will have the following values 
for those new columns: 


Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 


Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 
(geopriv@ietf.org) 


Schema: urn:ietf:params:xml:schema:pidf:geoprivl0:civicAddr 
Type: A 


Registration Template 


New registrations in the Civic Address Types Registry require the 
following information: 


CAtype: The assigned numeric CAtype. All new registrations will use 


the value 40. 


Namespace URI: A unique identifier for the XML namespace used for 


the extension element. 
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Local Name: The local name of an XML element that carries the civic 
address element. 


Description: A brief description of the semantics of the civic 
address element. 


Example (optional): One or more simple examples of the element. 
Contact: Contact details for the person providing the extension. 
Specification (optional): A reference to a specification for the 


civic address element. 


Schema (optional): A reference to a formal schema (XML schema, 
RelaxNG, or other form) that defines the extension. 


Type: "A" or "Bl. 
If Type is "A", all clients SHOULD implement this element. If 
Type is "B", clients MAY implement this element. 


8.4. Registration of the CAtypes Defined in this Document 


This section registers the following four new CAtypes in the Civic 
Address Types Registry. 


Post Number (see Section 5.1): 

CAtype: 40 

Namespace URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext 

Local Name: PN 

Description: Post number that is attributed to a lamp post or 
utility pole. 

Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 
(geopriv@ietf.org) 

Specification: RFC 6848, Section 5 

Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 

Type: A 


Milepost (see Section 5.2): 

CAtype: 40 

Namespace URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext 

Local Name: MP 

Description: Milepost: a marker indicating distance to or from a 
place (often a town). 

Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 
(geopriv@ietf.org) 

Specification: RFC 6848, Section 5 

Schema: urn:ietf:params:xml:schema:pidf:geoprivl10:civicAddr:ext 

Type: A 
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Street Type Prefix (see Section 5.3): 
CAtype: 40 


Namespace URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext 
Local Name: STP 
Description: Street Type Prefix. 


Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 
(geopriv@ietf.org) 

Specification: RFC 6848, Section 5 

Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 

Type: A 


House Number Prefix (see Section 5.4): 

CAtype: 40 

Namespace URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext 

Local Name: HNP 

Description: House Number Prefix. 

Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 
(geopriv@ietf.org) 

Specification: RFC 6848, Section 5 

Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 

Type: A 


8.5. Registration Policy and Expert Guidance 


The "CAtypes" registry is altered to operate on a registration policy 
of "Expert Review", and optionally "Specification Required" [RFC5226] 
if the element being registered has a Type value of "B". 


The registration rules for "Specification Required" are followed only 
if a registration includes a reference to a specification. 
Registrations can be made without a specification reference. 


If the element being registered has a Type value of "A", then the 
registration policy is "IETF Review" [RFC5226]. 


All registrations are reviewed to identify potential duplication 
between registered elements. Duplicated semantics are not prohibited 
in the registry, though it is preferred if existing elements are 
used. The expert review is advised to recommend the use of existing 
elements following the guidance in [RFC5774]. Any registration that 
is a duplicate or could be considered a close match for the semantics 
of an existing element SHOULD include a discussion of the reasons 
that the existing element was not reused. 


[RFC6280] provides a comprehensive framework concerning the privacy 
of location information as pertaining to its use in Internet 
applications. The expert reviewer is asked to keep the spirit of 
this document in mind when reviewing new CAtype registrations. 
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8.6. URN Sub-Namespace Registration 


IANA has registered a new XML namespace, as per the guidelines in 
[RFC3688]. 


URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr:ext 


Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), 
James Winterbottom (james.Winterbottom@commscope.com) 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http: //www.w3.org/TR/xhtml1/DTID/xhtmll1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> 
<head> 
<title>GEOPRIV Civic Address Extensions</title> 
</head> 
<body> 
<hl>Additional Fields for GEOPRIV Civic Address</h1> 
<h2>urn:ietf:params:xml:ns:pidf:geoprivl10:civicAddr:ext</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt"> 
RFC 6848</a>.</p> 
</body> 
</html> 
END 


8.7. XML Schema Registration 


This section registers an XML schema as per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:schema:pidf:geoprivl0:civicAddr:ext 


Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), 
James Winterbottom (james.Winterbottom@commscope.com) 


XML: The XML for this schema can be found as the entirety of 
Section 5.5 of this document. 
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